COMMENT ⊗   VALID 00020 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00003 00002	@Device[DOVER]
C00004 00003	@BEGIN(TitlePage)
C00006 00004
C00007 00005	@Chapter(Overview of Situation and Goal)
C00014 00006	@Chapter(Actual Dialogue)
C00022 00007	@\@BEGIN(TEXT1)
C00027 00008	@\@i{<Ok, so now we can readily tell, symbolically,
C00032 00009	KA:@\Ok, I have M-F, M-B, M-D and M-<rubout> under my belt. What now?
C00041 00010	@Chapter(Miscellaneous Editor Analogies)
C00048 00011	@Chapter(Predictions)
C00051 00012	@Chapter(Thoughts on this task/domain choice/...)
C00053 00013	@Chapter(Further tasks)
C00061 00014	@Chapter(Conclusion)
C00064 00015	@Appendix(For What Type of Pupil Is Analogy Appropriate?)
C00074 00016	@AppendixSec(Scrutiny)
C00081 00017	@AppendixSec(Other cases)
C00084 00018	@Appendix(Starting Set of Rules)
C00087 00019	@Appendix<(Starting) Description of Editors>
C00091 00020	@Appendix(Evaluating Body of Test Cases)
C00092 ENDMK
C⊗;
@Device[DOVER]
@Make[Report]
@INCLUDE(OVERHE.MSS[RDG,DBL])
@Use(Bibliography =  "GENL.BIB[RDG,DBL]")
@Use(Bibliography =  "REPN.BIB[RDG,DBL]")
@Use(Bibliography = "META4.BIB[RDG,DBL]")

@BEGIN(TitlePage)
@BEGIN(TitleBox)
@MajorHeading[Using Analogies For Knowledge Acquisition]

@Heading(A Scenario)
@END(TitleBox)

@i{@Value(Date)}

@Heading{Russell Greiner}
@B[Heuristic Programming Project
Computer Science Department
Stanford University]

@BEGIN[TEXT, Indent 0]
@C(Abstract):@\
@i{This report is an attempt to explain what an analogy is.
It first presents many examples of analogies.
This data is then used to define some of the properties 
which any analogy exhibits,
and a set of axes which characterize the space of analogies.
The concluding appendices discuss various related issues,
in particular the connection of models and reformulation to analogy.}
@END[TEXT]

@BEGIN(ResearchCredit)
This research was supported by the EURISKO grant from ONL;
and by Core Research funds provided by NLM and ARPA.
@END(ResearchCredit)

@END(TitlePage)

Russell Greiner
@END[TitleBox]
@C(Abstract):
This short scenario will demonstrate some of the ways
analogy can be used to facilitate a Knowledge Acquisition (KA) task.
The examples included show
the type of reasoning (we consider) necessary for this process.
@END[TitlePage]

@Chapter(Overview of Situation and Goal)

The main characters in this story are
a hypothetical expert system, ES,
and an (assumedly human) expert on EMACS, U.
Their mutual goal is to increase ES's "understanding" of EMACS;
achieved by teaching it more EMACS commands,
and by improving its understanding of previously known commands --
so ES will "know" better when to apply a given command,
and precisely what it will do.
(At a meta-level,)
our research goal is understanding how to use analogies to facilitate
this educational process.

@i{<It is worth mentioning early that this KA module will NOT generate analogies.
Its goal is to understand and use the ones it is given.
Also, note the importance of the interactive nature of this dialogue --
this program will first conjecture an interpretation of the analogy,
and can then ask questions along to attempt to confirm this...>}

For ES to profitably understand the analogies U may use,
it must initially "know" a little about EMACS, 
(i.e. a few of its basic commands)
and something about editors in general
-- including a description their purpose,
what sorts of things they are able to do, 
a body of relevant vocabulary terms, etc.
(Appendix @Ref(StartingInfo) justifies this claim, 
explaining why ES must start with some core knowledge, but not too much.)

ES has access to two (complementary) forms
of knowledge about editors and EMACS.
First, it includes ("procedural") rules,
which ES's inference engine can directly use to solve particular problems.
(These solutions will be in the commands to type into EMACS.)
Appendix @Ref(Rules) lists a subset of these problem solving rules.
ES also has a knowledge base of ("declarative") body of facts about 
editors in general,
instantiated with some specific facts about (what it now knows about) EMACS.
(A sketch of this semantic network is included in Appendix @Ref(EditorFacts).)

Both of the Knowledge Bases -- of rules and facts --
will be modified by the KA, the Knowledge Acquisition front-end to ES.
In addition to incorporating new rules/nodes/links,
KA may alter existing facts.
For example, we will see cases where an If clause of a rule is generalized,
and where the "topology" of a network is rearranged.
(Note that KA will not touch certain things 
-- like the rule interpreter and other control procedures.)

We've been rather flippant with our use of the term "understanding" --
just what does it mean to claim that ES now "understands" a new command?
Rather than follow a rather unnatural, and complicated structural
approach@Foot{
That is, we might insist that ES be able to produce the TECO code
corresponding to each new command.
(Note this is similar to a "derivation from first principles".)
However, this is more than most people could do, and not necessary.}
we will use a totally behavior criterion:
does ES use the correct commands in a given situation?
We will say ES has incorporated a new command if it uses
that command appropriately 
-- meaning that ES types that command when an EMACS expert,
(trying to minimize his keystrokes,)
would type it.

Appendix @Ref(TestBed) lists a small
battery of test questions,
generated before beginning this KA task.
Note we're still not sure just how these
questions should be posed -- that is, in what language to describe 
the initial and desired file (and other things, like current windows,
cursor position, etc).
One possibility is to design a new high-level editor-independent specification --
whatever that would be.
Another would be to type the appropriate E or BRAVO commands, and have them
translated into EMACS.
Comments?
@Chapter(Actual Dialogue)

Reiterating the above sitution:
An EMACS expert, U,
iq using the Knowledge Acquisition program, KA,
to teach an expert system, ES, 
more about the editor EMACS.
ES's knowledge is contained in the two Knowledge BaseS - RULES and EDITGRS.
KA has acceSs to both of these KBs, as well as basic facts about the nature
of analogies, Etc.  (See [Greiner - Thesis PRoposal, ca 12/81]).
Our goal is to figure how U can profitably use analogies in his descriptions
of new commands and classes of commands.

@BEGIN(TEXT1)
@i<The dialogue is rather Anglisized -- this is just to help me communicate
the core ideas... I am @B(NOT) planning to build a sophisticated Natural Language
front end.  Also, realize I am @B(NOT) claiming to know how to go about achieving
the various impressive derivations whiCh KA is able to perform below.
A de-cutesied dialogue, basEd on the below discourse, should be considered
αmy aspiration -- achievingit wilh require a great Deal More research, of course.>
@END(TEXT1)

-----
@BEGIN(Description)
U:@\Tell me what you now know about EMACS.

KA:@\I know about simple character movement/modification commands, and some 
file interface commands -- including how to visit a file and to save the
changes made.

U:@\Let me tell you about word commands:
They are just like single-character commands,
EXCEPT you hold down the Meta key rather than the Control key.

KA:@\I currently know about two classes of single-character commands:
single-character movement and character-modification.
Does this transformation apply to both of them?

U:@\Yes.

@BEGIN(Multiple)
KA:@\I know about the following character movement commands:
@BEGIN(DISPLAY)
C-F -- move the cursor forward one @i{character}
C-B -- move the cursor backward one @i{character}
@END(DISPLAY)
and the following character modification commands:
@BEGIN(DISPLAY)
C-D -- delete the current @i{character}
C-<rubout> -- delete the previous @i{character}
@END(DISPLAY)

Can I assume that
@BEGIN(DISPLAY)
Single character : C-F :: word : M-F?
@END(DISPLAY)
(Is this true for each of the 
C-F/M-F, C-B/M-B, C-D/M-D and C-<rubout>/M-<rubout> pairs?)
@END(Multiple)

U:@\Yes.

KA:@\Does it Make sense tk "move forward one WORD"?

U:@\Yes.

KA:@\Does the user type M-F to move forward one word?

U:@\Yes.

KA:@\Are the following commands correct?
@BEGIN(DISPLAY)
M-F -- move the cursor forward one @i{word}
M-B -- move the curqor backward one @i{word}
@END(DISPLAY)
and
@BEGIN(DISPLAY)
M-D -- delete the @i{word} the cursOr is pointing to
M-<rubout> -- delete the @i{word} immediately Before the cursor.
@EJD(DISPLAY)

U:@\Yes.

@BEGIN(Multiple)
KA:@\Ok, I now havE the "syntax".
At The risk of bobing you( let me show you what I knoW ngw∞
I analogized drom

@BEGINλDISPLAY)
MoveForwardSingleChar
   Isa~		CharacterMovEmaftCommand
   Direction:	Fo@IoCeH4∀@@@
βQCELt∩b~(@@A)eaKIπ!Ceft$ZAπQ¬eCGi∃dt∩E_@~∀∩%8A¬k
Sr[¬%ht∪π=]ie←0~∀@@↓¬Wk]⊃Cert$xy'2βπQβ.s⊃β?2β≠'3*aα;>|εβspQ(∧,TEλDM≥	H∃JHQ!PWεqQ hTλ(T<LeλDM≥	H∃JHQ)V␈6Xmwπ>≡,E≡Nl⎇F->},@hR∧∧∧O≡↔!⊂L≡≡&∞∨LZ$n␈l]V.wH8m]8;Y↓QHλλλM<Y8nM;{NA_[|]l≡Yβ"D∧λλpm<X	]α←FE⊂λ⊂*<`0edChars:	/ CharacteR8∧∩Eλ~∀$MaαW≤¬7JL-≡C@!39=⊃ Hλ∧λ[⎇;LL<X]α←FE ⊃e"∀"∩ih& VTFE∀P#0∂oT{Nodica that the teRms used here are making A rather¬
Strgng assumptiOn:¬
@i<viz.: that any co@5[CMHαβ∂π9ε∪∃β∪,≠?7C|ε6."
_NMh≥≥mt≤_<NNhβ"EU(≥~T_z_.8⎇→.$_;Y∧
=≤h∧]8p∃↑P14j≤β".
This issuE, of vocabulaby, is peitepated in Appendix @Ref(EXam).}
~∃%K]←e%]NAi!JAC@~k?→7N+QβWw≠C↔∂L3'↔⊃α⊃⎇MbβπK∃¬##↔K*βπ;e∧k'OS∞[↔Mβ≤yβ≠π∪x4*α,r⊃"↑]G&O
H	%⊃"C"JWP⊂∞'≠WεEεB%`] ↔*42P≠z42iλ1pp∪@∃`
βO,∧Vjπ,≡FF/$λm≥:;⊂.%KK@	↑<⎇λ	∀≤z≠nt≥~→-T_;∀mwc"J	M⎇→(∞M→>(≥≠λ∩≡Y(⊂$∧Oh@⊂≠w⊂:4→ty⊂)→yx2`#tive !Charq slOts.)
	αU:@\Fo.
~∃↓¬β∂∪8Q≠kYβ#'C3*H4*.RαrSF;/Mp↓α?;&yβS#*βGπ↔∞sS'∂~β?	β&C'Mβ≤{77πv!h4*Mε*π.YF/~∞,Vf/l≥g"πMtπ&F↑8R∧∧-86F∂,≤7&/)]w6.\XNH{{;,≥Y∨H
≥Y~8l≡→(≥
=λ⊂∩↑2qzj~w3FE≥44yP∪Tc⊂![vvpw→⊂;tv≠⊂6wk→P:42H1zy9[y⊂#7\;py2λ∀:yt[3P:4→P 4mQ4y2q]4ww?λ9v7z
P14FB !=f[{2c7\;pq2∀tw3v→kwy2∨≥ 4mHat0y≤⎇⊂1`(aracters (ignoRing boundary c@=]ISi%←]fR8~∃)Q¬hASf0A~[↓[@↔πw_4*α∀*≡&9D"&NBd
e$4T≠WKO⎇⊃6C?≡KS'?r↓ieα∨+KO?∩jC?OO#'?9αYα7?4*≠?K>K∩ONs∨3⊗>{K⊃i≤≠#πK~p4*α,r⊃"∩M~B2εJH4(4TKEβSFKMβ[∞cW∃1∧αn7⎇3⊗≠?↔;πK∩≡K;∨3-;?K∪sRβ'm≤≠#πK≥q1β¬∧≠?;O&;Q}∧3??SXh*;?&)βS#∂!βS#*β≠'3*β'Mβ⊗+';≥π∪↔CK/≠↔;S.!βπMε9βπ↔∪πe8hR'9β&C'Mβ≡O∃1π;∃∨3entation the system knew.
In general, there may be other descriptions -- and some work may be required
to decide which of these tk use.}
@END(Multiple)

U:@\No.

KA:@LHow do I compute it?

U:@\By moving enouch character to reach the end of a word.

KA:@\What is aword?@Foot{
Realize if KA already knew about words, we'd be done.  The "distance" slot
above would be tpiviAlly Filled in, with (essentially) a function which
advanced to the nexpλAo=eHAEIKCV\@~∃)!Sf@E¬]CY←≥rDAo=kYHAQQK\A	JAck%iJAk9S]iKIKgiS9N@L\8A[Ke∀AGQCICGiKHAgkEMiSikQS←\~)o←kY⊂AI↑\8]|~∀4∃*u↓qαAgiIS]NA=LAGQ¬eCGi∃efXA⊃KYS[%iKHA	rAg←5JAo←IHAgKAKeCi=d@QY%WJAgACGJA=`@~∃Ak]GiUCiS←8\R~∀4∀→↓9↓	∂∪≤!)1(DR~∃↓%vy)Q%fACaAe←CG AYKC⊃fAi↑↓BAeK→←e[k1CiS←8A←LAQQJAI∃gGeSAiS←\↓←LAB↓MSYJ8~∃∩OYJA←]1rAiQ∀AM←O≥SKgh↓←LA]=iS←]LAQ←n↓i↑ACUi←[CQJAiQ%fAae=GKgf8⎇|~∃↓∃λQQ1(b$~∀~∃-αu↓→=V\@A⊃↑AiQ∃gJ@E]←eHELAM←e4ABAa¬eiSi%←]S]≤A←LAQQJAM%YJ}~))QCh↓SfXA
C\AC9rAgKEkK]G∀A←LA
QCeC
iKdA	JAISYSIKH↓S]i↑↓BAgKEkK]G∀A←LA]←eIf|~∀~∃Tu↓93∃f\~∀4∃↓¬≥∪≤Q≠UYiSa1JR~∃-αu↓8!)QS]-S]NA¬Y←kH$A'↑A$AGC\↓IKgGISEJAQQJAGUeg←d↓a←gSQS←\A%\ABA→SYJA¬f~∃B↓aCSd0A↓Svqo←eH5a←g\0AGQCH[a←g8⎇|@Z4A[KC9S]NAQQJAGUeg←d↓SfAGUeeK]QYrAS8@~∃↓%wGQCH[a←g9|AGQ¬eCGi∃efAS8AMe←9hA←L↓iQJA↓Swo←IH[a←M]|[i Ao←e⊂~∃←L↓iQJA→SYJ\4∀~∃∪8AiQSLAeKaIKgK]QCiS←8XAG←9gSIKIS]NA
keg←H[!←g%iS←\↓]←nA¬fAB@H[λAm∃Gi←d0~∃ε[_A[KC9f~∃↓	∂∪≤!	∪'!1β2R~)πkeg=d[!←MSiS←8@tzA
keg←H[!←g%iS←\V@x`0b|X~)↓≥λ!	∪'!1β2R~(QKqG∃ahAo!K\Ai!JAGkIg←dA!CHAE∃K\ACPAiQJ↓K]HA=LABA]←eHR4∃C]H↓~[A5KC]f4∃↓¬≥∪≤Q	%'!→βdR~∃πUeg←d5!←gSQS←\@hzAπkIg←d[A←gSi%←\@VxbX`x\~∃↓∃≥λQ	%'!→βdR~∀~))QK\↓iQJA↓SvGπ!Ceg|↓gY←h↓gQ←k1HAEJEKqi∃]IKHλAi↑AQQJA↓%w	KYQC|v~)C]HA↓¬w≠←YK
←e]CeI'%]OYK
QCe|i↓Sw	∃YiC|z@x`0b|XA¬]H~∃5←mK
=eoCe⊃'S]O1K/←e⊂u	KYQB@z@pbX`|8~∀~∃%fAiQ%fAG←IeKGh|~∃↓9λQ≠k1iSaY∀R~∀~)*u↓9]KYXX↓ShA[%OQhA!CmJA	KK\X↓EkhA%hASg8Oh]↓→←←iv4∃≥←i∀AiQSLASfA]QChA!CaaK9fAoSQPAYS9JA[←YK[K]P@ZZA=]JAe∃[CS]LAiQJ↓gC[J↓]k[E∃d~∃←_AGQCICGiKIfAMe=ZAiQ∀AEKO%]]S]≤ACMi∃dABA[≤A←HAε[ ZZA←HACfA
Y←gJ↓i↑Ai!Ch~∃A←gSi%←\ACLAa←gMSEYJ9|~∃)<AKqa1CS\AQQSfA
←[[C9HA∩A]SYXA9KKHAQ↑A[C-J~∃i!JAIK→S]iS=\A←LEo←e⊂DA[←IJAae∃GSgJ8~∃Sh↓SfAB↓gieS9NA←LbA←d↓[←eJ↓G←]g∃GkiSYJ@~∀	eKOk1CdD@!↓SwR9J]|X↓]←\[⊃KYS[%iKdR↓GQCe¬GiKeLX~∃M=YY←o∃HAEr↓BAgiIS]NA=L@bA=dA[←IJAo←IHAIK1S[Si∃dAGQ¬eCGi∃ef\~))QJA4[AG=[[C]⊂ACYo¬sfAa1CGKf↓iQJA
keg←HAChAQQJAM%eghA⊃KYS[%iKdA→←YY←]S]N~)iQJA
keeK9h@Q←HA]KqPRAaCQGPA←_AeKOUYCdA
QCeC
iKef8~∃~[λACYo¬sfAa1CGKf↓iQJA
keg←HAChAQQJAM%eghAIKOkY¬dAGQ¬eCGi∃dA←L↓BAo←IH\~∃%\AOK9KeCX↓ShASLAoSi!S\Ai!JAGkIeK]h↓o←eHZZAk9YKgf↓s←jOIJACYIKCIr↓ChAi!J~∃gQCehA=LABA]←eHA]QK\AQQJAG=[[C]⊂ASfA%ggkK⊂\~∀~)↓¬∂%≤Q≠k1iSaY∀R~∃↔∧u↓9⊃5Z\A'<AaKe!CafA¬\ACaAe←ae%CiJAIKaeKMK]iCQS←\A=LAiQ∀AGkeM←dAa=gSiS=\ASf↓B~∃iISaYJh~∃↓	%'!→βevyo←IH[a←M\XAI∃YS[SQ←d}X↓GQCd5a←g\xY|~∃]QKeJ↓↓Swo=eH[a=g]|A!CfAi!JAgC5JA[K¬]S]N↓ShAQ¬HACE=mJX@4∃↓Sw⊃KYS[%iWd␈xASfA∧AESh0AS]I%GCiS9NAoQ∃iQKd↓iQJA
keg←HASfA9←nAS8~∃iQ∀A[SIMhA←L↓IKYS5SiKeLA←dAIKOkY¬dAGQ¬eCGi∃efX~)C]HA↓SwGQ¬d[a←M]|Ai∃YYfA!←nA[¬]rAG!CeCGQKefA→e←ZAQQJAgQCehA=LAiQ%fAgiIS]N\4∀~∀Q9←iJA$AQCH↓i↑AkMJAiQ∀AMCGPAiQCPAeKOUYCdA¬]HAI∃YS[SQKdAG!CeCGQKefA¬eJAI%gU←S9h\R~(~∃∩A≥←hAi!JAM←1Y←oS9NAMe=ZAoQ¬hAs←TAgCS⊂t~∃~5A[CAf~∀~)↓¬∂%≤Q	∪M!→β2$~∀y≤0@`XA4|@z|y≤X@DX@`|4∀y≤XbXA~x@z|@q≤VbXbX@`xv~∃↓	∂∪≤!)1(DR~∀xq≥←iJ↓]←\[QKe[S9CYfA¬eJAG¬aSiC1SuKHlAC]H`AS\↓iQJ@I]HAa=gSiS=\A[K¬]f~∃QQJAGUeg←d↓SfAa=S]iS9NAi↑↓BAeK≥kYCd↓GQCe¬GiKd0@bA[∃C]fAQ↑ABA⊃KYS[%iKd\x|~∃↓∃≥λQ)∃1(bR4∃↓≥⊂Q	∪'A→β2R4∃C]H↓~[∧A5Caf~(~∃↓¬∃∂∪≤Q⊃∪'!→¬2R~∀q≤X@`0@`|@t|@y≤4bX@`0@`|~(y≤X@@XA~|z|@y8X@`X`|∩∪mae←m%IKHA4|a:~(y≤X@DXA |z|@y8X@`X`|}~)↓≥λ!	∪'!1β2R~(~∃∪f↓iQSf↓G←ee∃Gh}~)↓≥λ!≠kYi%aYJR4∀~∃*i↓93KL\~∀~(→↓9↓%vy∨V0Ag↑A9←nAo∀AGC\↓eKCI%YrAi∃YXXAMs[E←1SGCY1rX~∃]QChA!CaaK9fAoQ∃\A~[_AC]H↓~[∧A¬eJAieaKH\4∃/JAMiSYX↓]KKH↓C\AC1O←eSQQ[SF↓IKgGISaiS=\A←L↓iQSf8~∃
kIiQKe5←eJX↓oJAgQSYXA9KmKd↓gCSH↓oQK\↓i↑ACAaYrAQQSfA
←[[C9H\⎇|4∀~∃↓	∂∪≤!≠kYi%aYJR4∃↔αu↓9'↑AQQJA~5ACY≥←eSi!ZASf4∀~∃↓	∂∪≤!!e←OIC[q¬[aYJ$~∃/⊃%→
A↓≥v5⎇	∃YS[SQKdPA
keeK9h[πQ¬d@RA⊃≡AβIYC]GJ5πQCd Rv~∃]⊃∪→
A	KY%[SiKHPAπkIeK]h5πQCdRA	≡↓βImC9GJ[π!CdPRl~∃βIYC]GJ5πQCd Rv~∃↓≥λQAe←Oe¬[qC5aYJR4∀~∃C9HA~[λASf~(~∃↓¬∃∂∪≤QAe←Oe¬[qC5aYJR4∃¬CG-+`[π!CdPRl~∃/⊃%→
@A⊃KYS[%iKdP↓πkee∃]h[π!Cd@R↓	≡A¬¬GW+`5πQCd Rv~∃]⊃∪→
↓↓Ov5y	KYS5SiKd AπkeIK]h[
QCd@$A	≡A	CGW+@[πQCHPRv~)↓≥λ!!e←OIC[q¬[aYJ$~∀~∃]QKeJ↓πkee∃]h[π!CdASLAiQJ↓Gkee∃]hAG!CeCGQKdAS8AiQJ↓MSYJ0~∃C]⊂AiQJ↓βImC9GJ[π!CdPR↓Mk]GQS←\A¬ImC]
KfAi!JAGkIg←dA=]JAa=gSiS=\X~∃]QSYJ↓¬CGWU`[πQ¬dPRA5←mKf↓iQJA
keg←HAECG,A←]J↓a←gSQS←\]↓
←←il~∃)Q%fAOKQfABA	ShA[∃ggrA¬e←k]⊂AiQJ↓EKOS9]S]N↓C]HA∃]HA←_ABAM%YJ@Z4~∃/J≥eJAg¬mJAS_AiQKIJACe∀A'∨↓C]HA∃∨@Q⊃KYS[%iWdR↓GQCe¬GiKeLAS\AQQ←gJ↓a←gSQS←]f9|~∃↓∃≥λQ≠UYiSa1JR~∀4∃*u↓q→←←WLAO←←⊂\~∀~)↔αu↓q∩Agi%YXAQ¬mJAi<AIKIUGJAo!K\Ai<ACGiUCYYr↓kgJAQQKgJ↓G←[[¬]If\4∃βfA∧Ao←e⊂AQCf↓[C]r↓YKii∃dXA∩↓Cggk5JA∩AMQ←kY⊂AkgJ↓iQJAMS]OY∀A~[↓G←[[¬]H~∃ICiQKHAiQC8ABAEU]GPA[XA]QK]KYKdAa=ggSE1J]↓
=←iv~))QKe∀ACeJ0A←LA
←keg∀XA[C9rA]k¬]GKf↓←LAi!Sf@Z4~∃M←HAKqC5aYJX↓iVAe∃CGPAQQJ@b@AGQCICGiKHA←LA¬\@bb↓GQCE¬GiKd↓o←eH0~∃O]∀Ao←k1HAae=ECEYdACIm¬]GJA=]JAo=eHX~)iQK\↓ECGV↓k`AB↓cSMO1JAGQ¬aCGi∃dXAe¬iQKd↓iQC\↓CAmC9GJAi∃\AGQ¬eCGi∃ef]|4∃πC\↓∩ACgMk[JAQQKgJ↓IKYS5SiKeLACeJ↓KCgrQM←d↓s←jA!k[C]LRAi↑↓gCJ}4∀∩¬*i↓93K@\~∀~)↓9↓)∃1(c7↓Svy≥=nAoQ¬hACE=khAi!JA←i!KdAi]↑AG←5[C]IL@ZA~5λXA~4yekE=kh|}y⎇:~∀4∃↔αu↓9)KY0A[JA5←eJA¬E←kh↓~[λA¬]HA~4yekE=kh|\4∀~∃*i↓9π←9gSIKHACYX↓iQJA
QCeC
iKef↓Me←Z↓iQJA
keeK9hAa←MSiS←8Ak`AQ↑AoQ∃eJ@~)~[A]←kYH↓aYCG∀AiQJ↓Gkeg=d\@@4∃~[λ↓IKYKQKfAC1XA←L↓iQKg∀AGQCICGiKIb\~∃MS[SY¬eYrA4Zyek	←kh|↓IKYKQKfAC1XA←L↓iQJA
QCeC
iKef↓Me←Z↓iQJA
keeK9hAa←MSiS←8~∃k`↓iVAo!KeJA4[∧Ao=kYHA!CmJAAYCGK⊂AiQJ↓Gkeg=d]↓
=←iv~)∨]GJ↓[SOQPAgCr↓~[@hA~[λptA~5∧@tA4Zyek	←kh|0AS\AQQSfAMK]gJ9|~∀~)↓¬∂%≤Q≠k1iSaY∀R~∃↔∧u↓9∨,XAg↑↓~[λA⊃←KfAQQJAM=YY←o%]N~∀4∃↓¬≥∪≤Q!I←OeC5qC[AYJR~)/⊃∪→∀A↓Ovi⎇	KY%[SiKHPAπkIeK]h5πQCdRA	≡↓	KYKQJ[πQ¬dPRv4∃/⊃∪1
@A	∃YS[SQKdPA
keeK9h[πQ¬d@RA⊃≡A	K1KiJ[
QCdP$v~∃β⊃mC]G∀[πQCHPRv~)↓≥λ!!e←OIC[q¬[aYJ$~∀~∃¬]HA~4yekE=kh|AAKeM←I[f~∀4∃↓¬≥∪≤Q!I←OeC5qC[AYJR~)¬CGWU`[πQ¬dPRv4∃/⊃∪1
@A	∃YS[SQKdPA
keeK9h[πQ¬d@RA⊃≡@~∀$y	KY∃iJ[π!CdPRlA¬CG-+`[π!CdPRxv~∃/!∪→
A↓Ov5⎇⊃KYS[%iKdP↓πkee∃]h[π!Cd@R↓	≡@~(∩y	K1KiJ[
QCdP$vA¬C
W+`[
QCdP$|~∃↓∃≥λQ!I←OeC5qC[AYJR~(~∃oQ∃eJA	∃YKiJ5πQCd RAIK1KiKf↓iQJAurrent character, in effect advancing the cursor.

Correct?
@END(Multiple)

U:@\Of course.

KA:@\And I'll use this whenever possible, as I would M-F to move?

U:@\Yes, for the time being. 
(As these deletions are destructive, this could be dangerous.  Fortunately
KA doesn't yet know about things like advancing too far, then backing up...)

KA:@\Ok, I have M-F, M-B, M-D and M-<rubout> under my belt. What now?

U:@\S-expression commands are just like WORD commands, except they
use M-C-@i{x} rather than M-@i{x}.@Foot{
Note this is better than saying they are just like character commands,
as an S-expressions is more like a word than a single character 
(in that both words and S-expressions have many characters).}

KA:@\So I can assume there are the following commands?
@BEGIN(DISPLAY)
M-C-F -- move the cursor forward one @i{S-expression}
M-C-B -- move the cursor backward one @i{S-expression}
M-C-D -- delete the current @i{S-expression}
M-C-<rubout> -- delete the previou @i{S-expression} immediately before the cursor
@END(DISPLAY)

U:@\Yes.

KA:@\What's an S-expression?

U:@\An S-expression is a string of characters, (recursively) defined as follows:
it is either an atom, or an opening parenthesis, "(", followed by a sequence
of atoms, seperated by spaces, and then a closing parethesis.

KA:@\The obvious question: what is an atom?

U:@\(For the time being, assume) it is a word.

KA:@\So 

<<<<here>>>>

@END(Description)
@Chapter(Miscellaneous Editor Analogies)

Related EMACS commands:

@BEGIN(DESCRIPTION)
Word commands are just like character commands,@*
EXCEPT they use @i{M-x} rather than @i{C-x}.

S-expression commands are just like word commands,@*
EXCEPT they use @i{M-C-x} rather than @i{M-x}.

Sentences are handled like lines,@*
EXCEPT the command is @i{M-x} rather that @i{C-x},@*
AND these commands refer to next sentence, not same line.@*
(recall line commands are for this line, and stay in place (idempotent)).

Buffers are like File Visiting,@*
EXCEPT @i{C-X B} to switch about files (info lost when visiting)@*
AND the file is not lost when next file is "encountered".

Windows are handled like Buffers,@*
EXCEPT they are visible (and so have fewer lines...),@*
ONLY two files at a time,@*
AND they use @i{C-X C-O/1/2} to switch between them, (not @i{C-X B})

@END(DESCRIPTION)

@Chapter(Predictions)

So far the analogies had a single use -- for U to communicate a bundle
of facts to ES, simply and quickly.
In the scenario given, the full derivation which KA had to produce to
note such connections might simply be thrown away after the result
(eg how to move forward one word) has been deduced.

There are (at least) one reason to maintain this information:
It could be used by KA to draw feasible inferences,
based on what it has seen so far.  
These plausible inferences would suggest other analogous connections
of commands,
based on those old analogies.
For example, if KA later found that C-T meant to
transpose the (single) characters in front of and behind the cursor,
it might ask whether M-T meant to transpose words.
Indeed this the case.
@Foot{This implies some method to this EMACS madness.
<Here: Designed artifact assumption.>}

Eventually systems of known analogies could be analyzed,
searching for regularities.
One observation is that C- seems to refer to lowest (physical) level,
and M- to the next (often logical) level.  
(Not only was this true in the characters/words case,
but also for lines/sentences.)
From this, one might infer that, as C-N goes up one line,
that M-N would go up, say, one paragraph. (Note this is faulty --
oh well.)
<<Need better Example>>

@Chapter(Thoughts on this task/domain choice/...)

This particular domain, of Editors, is clearly artificial.
"Understanding" EMACS requires a version of "designed artifact" notion:
the parts were designed for some reason; and if we can (re)construct that
reason, we'll be able to predict other aspects of the system -- ie other
parts probably used same type of justification...  Here, a reason might
be "ease of memory" (hence similar names for similar commands, and use nice
abbreviation (abbreviations for ease of use-- fewer keystrokes))
or commonly used instructions should be short, and concise (ie single
command).  Pedagogy - need to know certain basic ops for any editor. (See ?)

The role of this system is vaguely similar (analogous) to Davis' Teiresias
@Cite(TEIR-Thesis) --
helping the user to input new facts, possibly finding errors, (using, in this
case, some crude semantic information as well as the syntactic constraints).


@Chapter(Further tasks)

Now knowing about EMACS, try to learn E.
@BEGIN(Itemize)
@BEGIN(Multiple)
(As with EMACS,)
when two E commands perform a similar function,
expect their invocations to be similar.@*
[Deep reasoning: designed by humans for humans...]@*
Ex: @G(a)_ & @G(ab)_ related in E, (as are @G(a)_ and @G(a)X_,)
as C- and M- are in EMACS@*
(Consider @G(a)F and @G(a)XF, or @G(a)D and @G(ab)D...@*

[Note: this is not always the case - consider programming languages,
in which "WHILE ... DO ..." is quite different from the similar
"REPEAT ... UNTIL ...".]
@END(Multiple)

Same types of commands in E as in EMACS 
-- cursor movement, text substitution, movement, insertion...@*
[Deep reason: both are editors,
and the purpose of an editor is to perform some function...]

Some forms -- especially those which lead to an obscure function --
require many keystrokes.  In E, this is done by @G(a)X ___, which
is similar to M-X ___ in EMACS.@*
[Deep reason: all commands cannot be single character...]

Pages in E are like narrow window in EMACS 
-- serving to restrict search, general context, ...@*
[This shortens otherwise long searches, movements, ...]@*
Difference: E's pages are static, defined in a file,
whereas narrow windows are dynamically assigned in EMACS.

EMACS has mode -- as it is adaptable (note E is not...)
(similarly for sub-modes, user profiles, ...)

Modes in E - line input, vs page, vs ...
	(certain commands legal only in some modes, and some have different
	meanings in each.)

@G(a)> is like C-U C-N 
-- now makes sense to find other E commands which correspond to
C-U <x>.  Besides @g(a)<, there aren't any...

Note <alt> n C-V moves screen up n chars,
whereas @G(a)n<form> moves forward n screenfuls.

@G(a)N and C-X C-X (return to last mark) both go to other side of buffer, once it
has been deposited.
@END(Itemize)
 
Onto harder problems --
It is relatively easy to map from EMACS to Bravo or E 
-- as they are all full screen editors.
What about TECO or SOS?
(Note this TTY editors make quite different assumptions:
here, typing is expensive, and should be avoided.  Hence the user must
explicitly state he wants to see X before seeing it.)

Go from here to -- knowledge about Text Editors -- to more general knowledge
about Text Formatters, like TEX or SCRIBE.  Core facts, about words, spaceq,
etc, map over, but (few if any) actual commands will.

On another dimensiOn,
consiDer the EMACS to representation languages mapPing.
Both attempt to facilitate the storage and retrieval od inforeation.
The major difference is generality: RLS are not restricted↓i↑AI∃CYS]≤AoSi AaKqP\∩∀~)π←]g%IKdAαs?]βπ∪?∨K∞k7'≠8β3π≠?+π∂↔~β'9β>+;↔K∞`4)5jβ←#'≡A1β3N[∃β↔&KS ?.5Bε∂,Tε∞g=tε⊗∂<XBε}d∞6/∂\Yf≡/4
v $_{s-\;Y≤eD→=_ea"C"J⎇_=λ≤[⎇=∧9~=
}\h≥
t≤Y8-D≥{|MLλ≠8.πc"QM≥→<h≡Y(≠
≥y(→M≥~;Ydx8Z-l=≤k↓Q]{|LNh≠~-<(≤y.≡9;Xl↑h≠yD8⎇~-⎇\kλ¬eKH→.LiC"AQO∂∪nM→<H←_;<
L<h~-d⊃6⊂)Z∪Vn,→k⊃-↔/OAQ@@Chapter(Conclusion)

People seem amazing adept at transfering "knowledge" or "expertise" from
one field or task domain to another, similar one.
For example, it is considerably easier to learn a second editor than it was
to learn the first; likewise for the second programming language, or second
instrument, etc.
(This obvious fact has indeed been empirically verified, by @Cite(Rumelhart).)

Why is this?
Clearly much of the information one assimilates when learning EMACS is
about the concept of what an editor does, and about editors in general.
This general information provides an important framework/structure off of which
to hang the "new" facts about that second editor --
hence much of the Bravo facts can be viewed simply as instances of those
already understood general editor facts.

When this structure is explicitly known, (and exactly apt,)
this learning task can be considered simple instantiation.
However the student is usually unable to articulate this information --
it has been "compiled" into his competence with editors, or whatver.
In addition, there are times when the old facts -- when that existent
structure -- is not correct.  For example, E makes great use of pages,
which EMACS just barely knows about.

To use that old information, in both of these cases, requires analogical
thinking -- the ability to (i) reason from the known examples of EMACS in action
to understand what its sibling E is trying to do, and (ii) the ability to
construct a new framework from a slightly-inapplicable one, to handle the
new case.

This scenario demonstrated both forms of analogical reasoning at play.
Much research is required before any of this processing will be automated.
That is the basic goal of my research.

--- and its use in general for creating and updating the KBs an ES will need
to use.
@Appendix(For What Type of Pupil Is Analogy Appropriate?)
@Label(StartingInfo)

Ask yourself how you would teach EMACS to a person.
In particular, how would you alter your presentation based on
what your student already knows?
Whether you will be able
to (profitably) use analogy as a teaching tool should
depend heavily on his current state of knowledge.

To demonstrate this point, we present three vignettes, 
all on the theme of learning EMACS.
In all three cases,
the student enters knowing the various single character commands --
including single character movements (C-F, C-B) 
and single character modifications (C-D, C-<rubout>, insertion).
He is then told that
@BEGIN<DESCRIPTION>
(*)	WORD commands are just like CHARACTER commands, 
	 EXCEPT they use "Meta-" rather than "Control-".
@END<DESCRIPTION>
The accounts below will differ only in terms of the learner's prior knowledge.

I. Mr RankBeginner (RB for short)
knows nothing about text editors, and little or nothing about
computers in general.  
Learning those single character commands was a slow
and painful process; but he can now just barely
navigate about the file, and effect those changes he desires.

I claim he would find (*) rather confusing.
While it is easy to syntactically transform his internal rules -- from
@BEGIN<DISPLAY>
	"To move forward one character, type C-F"	(i)
@END<DISPLAY>
to
@BEGIN<DISPLAY>
	"To move forward one word, type M-F",		(ii)
@END<DISPLAY>
he would have no idea when to use this new M-F command.
Given that terms like "word" are novel and alien,
how could he know what it means to "move forward one word"?  
While RB has some notion of where the cursor is,
that definition is with respect to characters;
and some non-trivial reasoning would be required to map
that information over to understand what it means for the cursor to point
to the current word.

Of course the familiar interpretations of "word",
and the intuitive notion of current word position would provide him with
a good start at understanding this command.@Foot{
We will claim that a user "understands" a command if he is able to use
it appropriately -- defined using a battery of exercising tests.
See Appendix @Ref(TestBed).}
It does, however, lead to other questions.  
What does it mean to delete the previous word (which is M-<rubout>'s function)?
In particular, what happens when the cursor is pointing to a character
inside a word?

What about C-P and C-N?
Intuitively these commands say go up or down A SINGLE CHARACTER.
It is reasonable to ask if there are M-P and M-N commands;
and if so, what do they mean?

Etc, etc, etc. 
Without a few explicit examples in hand, RB would probably simply
ignore this "word" frill, and continue using the tried-and-true C-x commands
he understands.

II. Mr BeenThereBefore (BTB) is more computer-mature.
He has (expertly) used several editors before,
and from these experiences derived a good intuitive 
feel for what sort of things an editor is supposed to do,
and how it goes about performing these tasks.

In particular, he already has a framework dedicated to 
"types of movement commands",
which currently holds only the known C-F and C-B commands.
On hearing (*), BTB's task is relatively straightforward --
he needs only store the new M-F and M-B commands at the 
appropriate place in this structure.
(M-B and M-<rubout> fit into his pre-existing text-modification framework,
of course.)
As BTB already has a basic definition of "word"
(derived from his knowledge of editors in general,)
he can readily deduce (an approximation to) the semantics of these commands.
Finally, BTB's internal rules, which tell how and when to move about the file,
are more sophisticated -- instead of RB's 
@BEGIN<DISPLAY>
	"To move forward one character, type C-F",		(i)
@END<DISPLAY>
BTB has something like
@BEGIN<DISPLAY>
	"To move forward to a new position,
		use the largest movement command available."	(iii)
@END<DISPLAY>
From this, and facts which state that words are larger than single characters
(together with certain implicit facts 
-- for example, that our visual system allows us people to find word boundaries
very rapidly),
BTB can readily incorporate these new M-x commands.

Note BTB still has some "boundary type" questions to resolve.
He does not yet know precisely what constitutes a word in this system,
nor does he know the details of how these commands will behave.
What distinguishes his case from RB's is that 
BTB knows how to go about answering 
(or perhaps, guessing at the answers to)
these question:
First, he can make quite reasonable predications based
on what other editors (eg E) would do here 
-- refined by his knowledge of the qualitative differences between
those other known editors and EMACS.
(For example, EMACS is a character-based editor, while E is line-oriented.)
If BTB needs a more exact answer, he can perform simple experiments.
Note this requires that he make the (to him) obvious assumption that
there is both a method and a consistently to these commands --
a realization that poor RB would have had trouble accepting.
Another approach begins by figuring out how to find the exact documentation,
and reading that description.@Foot{
This deals with a sense of closure - or rather, of achieving it quickly
by virtue of having the proper slots and organizing framework.
Realize too BTB may find his existent frameword lacking, and have to fix it up.}

III. Our third inquirer is Mr KnowItAll (KIA). 
In addition to BTB's background, he also knows TECO thoroughly, and,
furthermore, has access to the EMACS source code.
The analogy offered above is almost pointless,
as KIA could have derived everything he needed from "first principles"
-- from facts about editors in general, and from the "definition" of EMACS.
He would, at best, appreciate being given this pointer,
which will help focus his search when next he 
seeks other cursor movement commands.
Like the slave in the Meno,
he has not have been taught anything new 
-- only provided with a modicum of direction.
@AppendixSec(Scrutiny)
@Label(Exam)

Let's now look more closely at these cases.

In case (I),
I imagine the analogy would go over RB's head -- or, at least, 
hd would have to be both very sharp, and quite diligent, to get anything from (*).
To fully utilize this new information, he would have to first generate
(something isomorphic to) the organizing heirarchy which both BTB and KIA
had from the start.
How could RB possibly know when to use M-F, and when C-F, unless he
had general cursor movement rules, like (iii)?
(Notice (iii)'s conclusion triggers other rules; and it is these which,
in turn, invoke a M-F or C-F.)
Rules like (iii) are pretty easy to generate once one has 
realized that both of those commands are designed to achieve similar results 
(i.e. forward cursor positioning).
It is through observations like this that the heirarchy is generated.@Foot{
So far we have included only Forward Direct Cursor Movements.
Once C-B and M-B are examined, it will be obvious these Backward Direct Cursor
Movements should be included as well. Eventually C-S search commands will be
added as well.
Realize this hierarchy establishes a particular, non-obvious cut at the world
-- along the functionality lines
(eg cursor movement) rather than keystrokes, which would have lumped M-F with
M-D.
Anyone with experience with editors will agree that this dimension is appropriate.}
Many expert system developers have commented that a large part of expertise
derives from having these appropriate structures around.

KIA, in Case (III), made essentially no use the analogy presented.
This points to the obvious observation on the role of analogical reasoning:
It should be used only when the more powerful, and/or more reliable, methods
are NOT available.
Of course, in this extreme case, 
KIA's knowledge of "first principles" obviated his need to be taught at all.

Consider the less exaggerated example,
where the user has learned that M-5 C-F will move the cursor
forward 5 characters,
and now wants to move the cursor forward by 7 characters.
It seems unproductive to tell him that M-7 C-F is analogous to M-5 C-F,
just replacing the 5 by 7 in both the command to type,
and in the resultant goal.
There is an obvious partition of the M-5 C-F command into two parts 
-- the repetition factor followed by the "primitive" command.  
One can infer from this that any number, <N>, can by substituted for the 5,
and cause the cursor to move forward that number of characters.

Analogy is not needed in this case, as we had a stronger infering strategy
-- of assigning semantics to individual parts of the command string.
Such decomposition analysis will always be preferable to analogical reasoning --
whenever it is possible.
(Ie we had to know that commands can be divided into independent parts.
Of course this is not always true -- consider ? command, where a C-U argument
means, ... or other types of commands which require long strings of characters
(as in M-X Query Replace<alt>...).)

Another example of this knowing-too-much problem is less clear,
but follows along the lines developed earlier in this paper.
Realize that KIA already "knows" EMACS's definition of words,
and hence merely has to hear the particular name for the 
"Move One Word Forward" command to insert that
into his master structure.
All of the essential details of the 
"semantics" of this command easily fall out using the obvious inheritance 
-- from his corpus of facts about first cursor movements units,
and then about words.

Anyway, based on what we discussed above,
Case (I) is way too difficult (for people, to say nothing of machines), and
Case (III) is fairly trivial.
This leaves us with Case (II) --
which is the type of situation on which this research will focus.
Reiterating: we assume the ES already knows some (but not all) of the relevant
first principles about the domain being investigated (in this case, editors).
Furthermore, it must have a non-trivial collection of known particular facts
which can serve as appropriate analogues for new objects.  (Here, knowing about
character movements was essential to begin explaining the function of the
word movement commands.)
Finally, that KA front-end part of ES must have some idea how to draw up and
use the analogies provided.
@AppendixSec(Other cases)

It is not immediately obvious how common this Case (II) is.
To demonstrate that these constraints are not that imposing, or unusual,
this subappendix will briefly list a few other instances of this type
of situation.
[Note this corresponds nicely with the second phase of the KA task
(given in @Cite(SACON)).  Here the evolving knowledge base has a basic
(if slightly erroneous) outline of the domain,
and much of the essential vocabulary.]

@BEGIN(Enumerate)
@B(Geology:)@*
@i{Known Domain Details:} The existent expert system LITHOS knows about the
	Saudi Arabian peninsula.@*
@i{Core Facts:} Imagine it also had some body of core facts about
geology in general.@*
@i{New Domain Details:} Using those first principles, explain to LITHOS that  
	western Europe is just like the Arabian peninsula, EXCEPT ...

@B(Chemistry:)@*
@i{Known Domain Detaids:} Imagine Dendral currently knows about hydrates.
	[R-C(OH	2-H].@*
@i{Core Facts:} Imagine iT knew enough chemisTry to realize that amifeS were like
	hydroxyl groups, and to deduce just how they were similar andhow
	different.@*
@i{New Domain Details:} One could Then propose teaching Dendral about
	ammoniates [R-C(NH2)2-H].

@B(Music:)@*
@i{Known Domain Details:} Ability to play a stringed instrument - here the violin.@*
@i{Core Facts:} Basic physics (vibrating string), crude knowledge of instrument
	design (adjacent (open) strings would be harmonious), music facts
	(including harmony...)@*
@i{New Domain Details:} Learning to play the Viola -- or even Piano or Recorder.

@B(Programming:)
	From InterLisp to MacLisp - or even Fortran
	(or, so that's an iteration, or pass by reference)
@END(Enumerate)
@Appendix(Starting Set of Rules)
@Label<Rules>

The below rules are included in the starting RULES Knowledge Base.
Their rule interpreter is an EMYCIN like inference engine, which
back-chains from a goal description down to primitive operations.

(The commands are written in the form
@BEGIN<DISPLAY>
	To do X, execute Y.
@END<DISPLAY>
This is easily translated into the standard
@BEGIN<DISPLAY>
	IF you want to achieve X, THEN Execute Y.)
@END<DISPLAY>

@BEGIN<DISPLAY>
To move forward a single character,
  Execute the command: C-F.

To execute the <X> command N times in a row,
  Execute <X> M times in a row, and then Execute <X> P times in a row,
	WHERE M+P = N.

To execute the <X> command 4 times in a row,
  Execute the command: C-U <X>.

To advance in the file,
  Execute a cursor movement command.

To Execute a cursor movement,
	WHERE the absolute position of the destination is known,
  Execute an absolute move command.

To Execute a cursor movement,
	WHERE the relative position of the destination, (wrt current pos'n,) is known,
  Execute an incremental move command.

To Execute a direct move command,
	WHERE that new position is in the current line,
  THEN move forward (some number of) characters.

@END<DISPLAY>

A rule which will be Learned:

@BEGIN<DISPLAY>
To move forward (some number of) characters,
	WHEN there is a word boundary before that destination,
  Execute the command: M-F.
(There are now one fewer word boundaries between your position and the destination.)
@END<DISPLAY>
@Appendix<(Starting) Description of Editors>
@Label<EditorFacts>

Part of the EDITOR Knowledge Base.
We list below first a vocabulary, and then a list of operations.
Consider how you would fit Your favorite eDitor into this framework.
(Note match probably not exact -- eg where is multiple screens - or for that
matter, buffers?  Not in E.)

Vocubulary:
Character, String, (Word?)
Forward, Backward, (Up, down, previous next)
Position
Search, substitute
Delete, Insert
Move, Copy

@BEGIN<DISPLAY>
Operations
I. Cursor movement
  A. Direct, incRemental
    (Forward vs Backward)
    (Char [F&B], Line [U&D], Page [Next, Previous]
  B. Direct, Absolute
    (Char, Line, Page)
	1. Goto absolute poition
	2. Return to priop position 
  C. Indirect
    (Forward or Backward - or wrap around)
    (Restricted vs Unrestricted)
	1. Search

II. Text Modification
  A. Local [wrt Cursor]
    (Char vs string of character)
	1. Insert
	2. Delete
	3. Overwrite
  B. Global
    (Full file vs Rest of file)
	1. Substitution
	2. (Massive) Text deletion
	3. Text movement

III. Interface to Operating System
  A. File Management
	1. Enterring a file
	2. Saving current image
	3. Exiting
	4. Restoring previous version
  B. Other Forks
	1. (Returning to) superior fork
	2. Calling an inferior fork
	  a. and dumping user there
	  b. and doing something there

IV. Commands which effect other commands
  A. Local effects (effecting only single command)
	1. Repeat (Do this many times)
	  a. Absolute value
	  b. Until condition met
	2. Undo prior command
	3. Doc vs Execute (short term mode)
  B. Global effects (from now on)
	1. Macros
	2. Modes
	3. User initialization package
@END<DISPLAY>

------
@BEGIN<DISPLAY>
		Files
		/|\
	Window	Mark	Paragraphs

    Lines	Sentences	S-expressions
	
		Word

		Character

[note logical vs physical]
@END<DISPLAY>
@Appendix(Evaluating Body of Test Cases)
@Label<TestBed>

Validating ES's knowledge will involve giving the system some
task to solve, and watching its behaviour.
(Example task: Given a file containing xxx, find the 3rd occurence of yyy
following the cursor, which is now at position zzz.)